ftell() not consistent in C11 by damorinCan · Pull Request #8360 · cppcheck-opensource/cppcheck

damorinCan · 2026-03-21T16:45:33Z

Some legacy tools stopped suddenly working after 20+ years.

https://stackoverflow.com/questions/79762122/ftell-no-more-returning-the-correct-offset-on-a-text-file-with-windows-11-ente

chrchr-github · 2026-03-21T18:29:28Z

Thanks for your contribution.
As far as I can tell, this has nothing to do with Windows 11, but rather the C11 spec of ftell(), right? So the title of the PR should be adjusted.
Please add a test.

damorinCan · 2026-03-21T21:42:01Z

So the title of the PR should be adjusted.

Title now including reference to C11 and removed reference to Windows 11.

Please add a test.

I added a test in test/testio.cpp. Anything missing in it ?

chrchr-github · 2026-03-21T21:48:12Z

Please add a test.

I added a test in test/testio.cpp. Anything missing in it ?

Thanks, I must have missed that.

chrchr-github · 2026-03-24T08:08:23Z

Ping @danmar

danmar

I feel we need to have a ticket for this in trac

it feels like it should be added to the release notes as a "new check" ?

danmar · 2026-04-09T12:04:48Z

                case Filepointer::Operation::UNIMPORTANT:
                    if (f.mode == OpenMode::CLOSED)
                        useClosedFileError(tok);
+                    if (isftell && windows && f.read_mode == Filepointer::ReadMode::READ_TEXT && printPortability)


the error message says something about the C11 standard. Nothing about windows.

I will add a comment about this reference to this Microsoft page:

https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/ftell-ftelli64?view=msvc-170

An update for the error message with this, would it be OK ?

According to Microsoft, the value returned by ftell may not reflect the physical byte offset for streams opened in text mode, because text mode causes carriage return-line feed translation. See also 7.21.9.4 in C11 standard.".

I will remove the reference to _wfopen(), it's not part of the C++ standard.

Sorry.. my confusion was because you wrote && windows &&.

Now that I understand the issue better I think it's better to be clear that it's a standard problem.

danmar · 2026-04-13T10:56:59Z

I have tried to add some descriptions about some of our checkers here:
https://github.com/danmar/cppcheck/tree/main/man/checkers

Ideally that would contain descriptions for all our checkers but due to lack-of-resources it does not.

If you can add a corresponding file for this checking that would be great.

- Fix the uncrustify check (removed https reference to Microsoft). New changes: - Added missing string related to new check - Added checker description for ftellTextModeFile - Updated copyright.

sonarqubecloud · 2026-04-18T16:33:26Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

danmar · 2026-04-24T20:15:31Z

We need a ticket in trac for this.

Can you please tell me what you think the summary and description should be and we can create it..

danmar · 2026-04-24T20:23:14Z

@@ -0,0 +1,52 @@
+# ftellModeTextFile 
+
+**Message**: According to Microsoft, the value returned by ftell may not reflect the physical byte offset for streams opened in text mode, because text mode causes carriage return-line feed translation. See also 7.21.9.4 in C11 standard.<br/>


It's not according to Microsoft. It's according to the C standard.

Sorry I was confused before.

I think it would make sense to quote the text from the C standard in the description in this document and highlight the part that says its file position indicator contains unspecified information.

The ftell function obtains the current value of the file position indicator for the stream
pointed to by stream. For a binary stream, the value is the number of characters from
the beginning of the file. For a text stream, its file position indicator contains unspecified
information, ...

danmar · 2026-04-24T20:44:17Z

 /* -*- C++ -*-
 * Cppcheck - A tool for static C/C++ code analysis
- * Copyright (C) 2007-2025 Cppcheck team.
+ * Copyright (C) 2007-2026 Cppcheck team.


this diff is not needed. we don't tweak it manually.

danmar · 2026-04-24T21:51:43Z

+              "     if (f)\n"
+              "     {\n"
+              "         fseek(f, 0, SEEK_END);\n"
+              "         (void)ftell(f);\n"


I would think a warning here is a false positive. We can clearly see that nothing unexpected happens. The program will do what the developer expects. An assignment of an unknown or global variable pos = ftell(f); would make it more dangerous.

danmar · 2026-04-24T21:58:39Z

+     if (f)
+     {
+        fseek(f, 0, SEEK_END);
+        printf( "Offset %d\n", ftell(f);


Could we make the example code more "buggy"? If the program writes the offset for debugging purposes this output might be 100% fine. If the program writes "File size: %d\n" instead it would be a bit more clear it's a bug imho. If you have better suggestions to make it more "buggy" feel free to do it..

ftell() have a different behavior in Windows 11 than before.

14d63ab

https://stackoverflow.com/questions/79762122/ftell-no-more-returning-the-correct-offset-on-a-text-file-with-windows-11-ente

damorinCan changed the title ~~ftell() have a different behavior in Windows 11 than before.~~ ftell() not consistent in C11 Mar 21, 2026

danmar reviewed Apr 9, 2026

View reviewed changes

Applied comments.

1876e70

Major issue:

89e02be

- Fix the uncrustify check (removed https reference to Microsoft). New changes: - Added missing string related to new check - Added checker description for ftellTextModeFile - Updated copyright.

danmar reviewed Apr 24, 2026

View reviewed changes

		@@ -0,0 +1,52 @@
		# ftellModeTextFile

		Message: According to Microsoft, the value returned by ftell may not reflect the physical byte offset for streams opened in text mode, because text mode causes carriage return-line feed translation. See also 7.21.9.4 in C11 standard.<br/>

Conversation

damorinCan commented Mar 21, 2026

Uh oh!

chrchr-github commented Mar 21, 2026

Uh oh!

damorinCan commented Mar 21, 2026

Uh oh!

chrchr-github commented Mar 21, 2026

Uh oh!

chrchr-github commented Mar 24, 2026

Uh oh!

danmar left a comment

Choose a reason for hiding this comment

Uh oh!

danmar Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

damorinCan Apr 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danmar Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

danmar commented Apr 13, 2026

Uh oh!

sonarqubecloud Bot commented Apr 18, 2026

Quality Gate passed

Uh oh!

danmar commented Apr 24, 2026

Uh oh!

danmar Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danmar Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

danmar Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

danmar Apr 24, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

damorinCan Apr 11, 2026 •

edited

Loading

danmar Apr 24, 2026 •

edited

Loading